home *** CD-ROM | disk | FTP | other *** search
/ AOL File Library: 4,101 to 4,200 / aol-file-protocol-4400-4101-to-4200.zip / AOLDLs / ADV - Articles & Misc / Human Interface Tech. Notes / HIN.shk / HINNOT / HIN.010...ALER < prev    next >
Text File  |  1991-07-28  |  8KB  |  104 lines

  1.  
  2. _____________________________________________________________________________________________
  3.  
  4. Note #10    Alert Box Guidelines
  5.  
  6.     Written by:  John Sullivan    June 1990
  7.     (Slightly plagiarized from Kate Gomoll)
  8. _____________________________________________________________________________________________
  9.  
  10. Some simple rules to follow for alert boxes.
  11. _____________________________________________________________________________________________
  12.  
  13.  
  14. Why there are alert box guidelines
  15.  
  16. From the feedback the Human Interface group has received, it is clear that the discussion of alert boxes in Human Interface Guidelines:  The Apple Desktop Interface is both imperfect and incomplete.
  17.  
  18. These guidelines serve at least three major purposes.  First, they provide a simple recipe for making attractive alert boxes.  Second, they provide a simple recipe (the same one, in fact) for making alert boxes that have a standard appearance and behavior.  This standardization is important, because the more familiar the appearance of an alert box is to users, the easier it is for them to concentrate on the specific message being communicated.  Finally, these guidelines provide simple rules that can be extended for designing more complicated dialog boxes.
  19.  
  20. This Note supplements and partially replaces the discussion in Human Interface Guidelines:  The Apple Desktop Interface, so where this Note and the book disagree, believe this Note.
  21.  
  22.  
  23. Alert box layout
  24.  
  25. Alert boxes drawn with the toolbox calls _StopAlert, _NoteAlert, and _CautionAlert place the icon in the rectangle (top = 10, left  = 20, bottom = 42, right = 52); however, placement of all other elements is left to the individual designer.  Figure 1 shows a simple alert box in which spacing between elements is based upon this placement of the icon.
  26.  
  27.  
  28.  
  29.  
  30. Figure 1╨Simple alert box with spacing
  31.  
  32. Following are the exact coordinates used in Figure 1 and how they were derived, in Rez format.  Note that there are three white pixels built into the dialog frame and that the upper left corner of the text item is not the same as the upper left corner of the first character.
  33.  
  34. The first set of definitions are not actual coordinates, but instead are intermediate values used to derive them:
  35.  
  36. #define A                    13    // white space between most elements
  37. #define B                    23    // white space to left and right of icon
  38. #define NumTextLines          3    // number of lines of text in the alert
  39. #define LineHeight           16    // height of a single line of Chicago-12
  40. #define ButtonHeight         20    // standard button height
  41. #define LongestButtonName    41    // width of ╥Cancel╙ in Chicago-12
  42. #define ButtonWidth          59    // (LongestButtonName + 18)
  43.  
  44. The rest of the definitions are actual coordinates defining the window size (AlertWidth and AlertHeight) and the icon, text, and button locations:
  45.  
  46. #define AlertWidth          341    // chosen to make the right margin = A
  47.  
  48. #define IconLeft             20    // (B - 3)
  49. #define IconRight            52    // (IconLeft + 32)
  50. #define IconTop              10    // (A - 3)
  51. #define IconBottom           42    // (IconTop + 32)
  52.  
  53. #define TextLeft             74    // (IconRight + (B - 1))
  54. #define TextRight           331    // (AlertWidth - (A - 3))
  55. #define TextTop               7    // (A - 6)
  56. #define TextBottom           55    // (TextTop + (NumTextLines * LineHeight))
  57.  
  58. #define ButtonTop            68    // (TextBottom + A)
  59. #define ButtonBottom         88    // (ButtonTop + ButtonHeight)
  60. #define ActionButtonRight   331    // (AlertWidth - (A - 3))
  61. #define ActionButtonLeft    272    // (ActionButtonRight - ButtonWidth)
  62. #define CancelButtonRight   259    // (ActionButtonLeft - A)
  63. #define CancelButtonLeft    200    // (CancelButtonRight - ButtonWidth)
  64.  
  65. #define AlertHeight          98    // (ButtonBottom + (A - 3))
  66.  
  67.  
  68. The action button
  69.  
  70. Alert boxes that provide the user a choice should be worded as questions to which there is an unambiguous, affirmative response.  The button for this affirmative response is called the action button.  Whenever possible, label the action button with the action that it performs.  Button names such as Save, Quit, or Erase Disk allow experienced users to click the correct button without reading the text of a familiar dialog.  These labels are often clearer than words like OK or Yes.  Phrase the question to match the action that the user is trying to perform.  For instance, if the user selects Revert to Saved, the confirmation alert should say something like ╥Revert to the last saved version of the document?  Any changes made since the last save will be lost.╙  This message is much clearer than something like ╥Discard changes made since the last save?╙
  71.  
  72. If the action cannot be condensed conveniently into a word or two, use OK.  Also use OK when the alert is simply giving the user information without providing any choices.
  73.  
  74.  
  75. The cancel button
  76.  
  77. Whenever possible, provide a button that allows the user to back out of the operation that caused the alert box to be displayed.  This button is activated when the user types Command-. (period) or presses the Escape key.  (Note that the Command key sequence may differ depending upon the script system in use.  See Macintosh Technical Note #263, International Canceling, for more information.)  Apple recommends naming this button Cancel, so that users can easily identify it as the safe escape hatch.  For more information, see Human Interface Note #5, ╥What Cancel Means.╙
  78.  
  79.  
  80. The default button
  81.  
  82. In most cases, the default button should perform the most likely action (if that can be determined).  This usually means completing the action that the user initiated to display the alert box in the first place; therefore, the default button is usually the same as the action button.  The default button is boldly outlined, and its action is performed when the user presses the Return or Enter key.
  83.  
  84. If the most likely action is dangerous (for example, it erases the hard disk), the default should be a safe button, typically the cancel button.  If none of the choices are dangerous and there is not a likely choice, then there should be no default button.
  85.  
  86.  
  87. When there is no default button, the user must explicitly click on one of the buttons (pressing Return or Enter does not perform an action).  By requiring users to explicitly click on a button, you can protect them from accidentally damaging their work by pressing the Return or Enter key out of habit.
  88.  
  89.  
  90. Buttons (placement, size, capitalization, and feedback)
  91.  
  92. Put the action button in the lower right corner, with the cancel button to its left.  Use this placement regardless of which button is the default button; put the action button in the lower right corner even if the cancel button is the default.
  93.  
  94. Buttons in alert boxes look best when they are 20 pixels high (not counting the default button outline) and have at least 8 white pixels on either side of each button╒s name.  These specifications mean that the width of the button should be at least 18 pixels larger than the width of the longest button name (16 pixels for the white space plus 2 pixels for the edges).  It looks best to make all buttons the same width, unless the buttons╒ names have extremely different length names.  If you find yourself tempted to make buttons with extremely long names, reconsider the names carefully; button names should be simple, concise, and unambiguous.
  95.  
  96. Capitalize the first letter of each button name, but never capitalize the entire name╤with the single exception of the OK button.  The OK button should always be named OK and never ok, Ok, Okay, okay, OKAY, or any even stranger variation.  If a button name contains more than one word, capitalize each word, such as Replace All or Cancel Printing.
  97.  
  98. As in all dialog boxes, any buttons that are activated by key sequences must flash to give visual feedback as to which item has been chosen.  A good rule of thumb is to invert the button for eight ticks; this is long enough so that it is always visible, but short enough that it is not annoying.  Alert box calls in the Toolbox use the eight tick value by default.
  99.  
  100. ______________________________________________________________________________
  101. Further Reference
  102.  
  103. Ñ    Human Interface Note #5, What Cancel Means
  104. Ñ    Macintosh Technical Note #263, International Canceling